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Reusable components 


U sing a graphical user interface builder like Visual- 
Works’ Canvas tool and ObjectShare’sWindow Build¬ 
er Pro, a developer avoids the tedious task of hand 
codingan application window’s layout by usingatool that 
generates the code after the window is constructed visual¬ 
ly. Using such GUI builders, developers view a window’s 
appearance when opened and how it appears when re¬ 
sized before ever executing a line of the application win¬ 
dow's "real" code. These tools permit a developer to iden¬ 
tify what application methods should execute when spe¬ 
cific events, such as the clicking of a button, occur in the 
application window. Good ones will write method stubs 
that developers subsequently complete to perform the 
required reaction to given events Reaction methods often 
send messages to business objects to set or retrieve infor¬ 
mation about them and may force the window to update 
its views. Although these tools no longer require that 
developers hand code an application window’s layout, 
they still require them to implement the interaction 
between the views and the underlying business domain. 

ThelatestgenerationofGUI buildersincludetoolssuch 
as VisualSmalltalk’s PARTS Workbench and IBM’s Vis¬ 
ual Age Composition Editor. Both GUI builders are exam¬ 
ples of the new Construction from Parts technology called 
Visual Programming. They enable developers to create 
windows and other components by assembling and con- 
nectingreusablecomponents, also known as parts. Rather 
than hand-coding the interactions between the parts, 
developers make visual connections between a source 
part’s events and another part's actions. The GUI bui Iders 
still write Smalltalk code to construct the window for the 
developer, but, in addition to layout code, they also write 
code connecti ng events on parts to the execution of meth- 
odson others. Provided thatthere are good parts, develop- 
ersdo not need to writeanySmalltalkcodeto develop their 
application windows.Theyjustassemblethemfrom exist¬ 
ing parts and say "go". However, without guidelines, it is 
now possibleto paint spaghetti instead of just writing it! 
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The success of visual programming depends on how 
organizations useitand on the availability of a rich library 
of reusable generic and domain-specific parts. This col¬ 
umn will focus on visual programming tips and tech¬ 
niques to help you become a more effective visual pro¬ 
grammer. Future columns will cover how to manage the 
number of connections in your window and describe 
visual debugging techniques. We will also provide many 
examples of reusable components developed using visual 
programming parts and techniques, such as an advanced 
factory part, a broker, a marquee, and web parts. Initially, 
we will use examples derived from IBM’s VisualAge for 
Smalltalk environment, but we will include examples 
from ParcPIace-Digitalks next product release. 

This column describes the building blocks for con- 
structingany application window: parts and connections. 
As an example we bui Id an Action List Window with IBM’s 
Visual Age using only those building blocks—no Smalltalk 
code. The window's requirements are to let a user enter 
any number of actions into a To-Do list and then move 
them to a Completed list. Our goal isto demonstrate that, 
when given thebuildingblocksand good reusablecompo- 
nents, you can do a substantial amount "programming" 
without writing a single line of code. Be warned thatvisual 
programming rarely, if ever, providesa complete solution. 

REUSABLE COMPONENTS (PARTS) 

Before one can do any visual programming, one must 
have access to, or must create, a number of reusable com¬ 
ponents (parts). There are two different types of parts: 
Visual and Nonvisual. Visual parts have visual representa¬ 
tions and appear in a runtime application window, for 
example buttons, lists, input fields, and labels. Nonvisual 
parts have no visual representation, such as a Printer, CD 
player, Ordered Collection, Variable, and any domain- 
specific business parts. Nonvisual parts implement ob¬ 
jects that provide logic, storage, and resource access for 
your application windows. Visual and Nonvisual parts are 
simply assemblies of visual and nonvisual parts. 

In VisualSmalltalk's PARTS, all parts in the Workbench 
are i nstances of Smal Ital k cl asses The part's defau It inter¬ 
face includes all the messages the Smalltalk object under¬ 
stands and all of the events it can trigger. In IBM’s Vis¬ 
ualAge, all parts in the Composition Editor are Smalltalk 
classes. The part’s default interface is empty until the 
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developer decides what portion of the part's Smalltalk 
class' interfaceto makepublic. 

A part’s interface includes attributes, events, and ac¬ 
tions. Attributes represent properties of a part, such as the 
name of an empl oyee, that other parts access. An attri bute 
can be any Smalltalk object, including other visual and 
nonvisual parts. Onecan initialize a part's attributes using 
a GUI builder’s property or settings tool at development 
time or can access them dynamically at runtime. Actions 
are an operati on that a part executes when events on other 
parts trigger them. For example, a button click event (gen¬ 
erated when the user clicks on the button in the applica¬ 
tion window) could trigger a window's close action. Ac¬ 
tions correspond to Smalltalk methods or codefragments. 
Events are signals that one part can send to another to 
notify it that something has occurred. 

CONNECTIONS 

A developer specifies relationships between parts by mak¬ 
ing connections between them. The first type of connec¬ 
tion is an event-to-action connection. This link connects 
an event of one part with the execution of another part’s 
action. When the event triggers, the action executes. The 
second type of connection is an attri bute-to-attri bute 
connection, which can be viewed as a two-way event-to- 
action connection. The change of one part’s attri bute (the 
event) tri ggers the setti ng of the second part's attri bute to 
the same value (the action), and vice-versa. 

AI i n k, al so cal I ed con n ecti on, i s a typeof part. Th erefore, 
it has attri butes and events The attributes of a connection 
correspond to the parameters that the action at the end of 
theconnection requires and theaction's result. If an action 
requires no parameters, the connection has only one at¬ 
tribute: a result. Since actionsjust execute Smalltalk code, 
theconnection storesthe result object as an attribute. Since 
the setting of an attribute is equivalent to an event, it is 
possible to make a connection between the result event 
and other actions. One can trigger an action on another 
part when a previous action finishes and returns a result. 

Events may or may not generate parameter values. For 
example, the clicking of a button only triggers a click 
event. On the other hand, the selection of an item in a list 
generates a selection event and provides the selected 
object as an argumentfor a connection to useasoneof its 
parameters. Of course, one can change the value by mak¬ 
ing a connection to the link. 

VISUAL PROGRAMMING EXAMPLE 

Visual programming permits developers to quickly con¬ 
struct application windows provided the appropriate 
parts are available Using VisualAge for Smalltalk version 
3.0, we quickly constructed the "ActionListWindow" 
shown in Figure 1. This window allows the user to con¬ 
struct a list of actions to do for the current day. From that 
list, completed actions can be moved to a completed 
action list. At the end of the day, the user should have all 
of his or her actions in the completed actions list (ha ha)! 



Figure l.ActionListWindow in the Composition Editor. 


Figure 2. ActionListWindow Connections. 

Thisfirst-passoftheActionListWindowcontainsseveral 
visual parts, two nonvisual parts, and a few connections. 
Theordered collection* part,"ActionsTo Do," is connected 
to the I eft-most list with an attri bute-to-attributeconnec- 
tion. The collection’s "self" attribute* is connected to the 
list's "items" attribute. This connection specifies that the 
ordered collection storestheitemstodisplay-iftheordered 
collection changesin anyway, thechange is automatically 
reflected in thelistbox. Asi mi larconnection linksthe“self" 
attribute of the ordered collection titled "Actions 
Completed" to the"itemsf' attri buteoftheright-most list. 

The "clicked" event of the push button labeled "Add" is 
connected to the "add:" action of the "Actions To Do" 
ordered collection through an event-to-action connection. 
The "add:" action requi res a parameter. We specify the con¬ 
nection parameter with an attribute-to-attribute connec¬ 
tion from the "anObject" continued on page28 


* An ordered collection holds any number of Smalltalk objects in the 
order in which they are added. 

t In VisualAge, all parts have a "self" attribute This attribute repre¬ 
sents the whole part. 













































































VISUAL PROGRAMMING 


Link #PartName.attribute/event/action -> 

PartName.attribute/ event/ action 

1. ActionList.items 'Actions To Do'.self 

2. ActionsCompletedList.items 'Actions Completed'.self 

3. AddButton.clicked —^ 'Actions To Do'.add: 

4. inputField.object connections.anObject 

5. »Button.clicked -> 'Actions Completed'.add: 

6. ActionsCompletedList.selectedltem connections.anObject 

7. button.clicked 'ActionsTo Do'.remove: 

8. Acti on sCompi eted Li st. selected I tem connection?. anObject 

Figure 3. ActionListWindow Legend. 

continued from page 25 attribute of the original connec¬ 
tion to the "object" attribute of the entry field. These two 
connections provide the ability to add objects to the 
ordered collection. Any objects added are automatically 
displayed by the connected list. 

Clicking the "move" button, labeled"»," moves the se¬ 
lected item from the left-most list to the right-most one. 
Objects removed from the"ActionsTo Do" ordered collec¬ 
tion are added to the "Actions Completed" ordered collec¬ 
tion. Theorder of thefollowingconnections is important.* 
The"cl i eked" eventof the"move" button i scon nected to the 
"remove:" action of the "Actions Completed" ordered col- 


* Once you remove an object from an "Action To Do” ordered collec¬ 
tion, it is no longer in the left-most list. Therefore, it can no longer 
be the selected item and cannot be moved to the "Actions 
Completed" ordered collection. 


lection.Thisevent-to-action connection requiresan object 
(the object to be removed) that is supplied by connecting 
the"anObject" attribute of theevent-to-action connection 
to the "selected I tem" attribute of the left-most list box. 
The "move" button's "clicked" event is also connected to 
the "remove:" action of the "Actions To Do" ordered 
collection, with the "anObject" parameter supplied again 
by the "selected I tem" attribute of the left-most list box. 

Clearly, we require a better way of describingthe con¬ 
nections—textual descriptions are too long. A concise 
connection representation is both desirable and neces¬ 
sary. Figure 2 shows our Action List Window again, but 
this time we have added line labels (unfortunately 
VisualAge does not provide this facility for us) and Figure 
3 shows the legend. 

IN THE FUTURE 

To keep this example small, we have avoided certain is¬ 
sues. The push button is not disabled when its does not 
apply. The "move" button should be enabled only when 
there is a valid selection in the left-most list box. The 
"Add" button should be enabled only when the user has 
entered data in the entry field. Perhaps some ability to 
remove items from one or both lists might prove useful. 
Ultimately, the information needs to persist in someway. 
These are issues we intend to address in future columns. 

THE CODE 

The code used in this column is available on the World 
WideWeb. Our URL ishttp://www.objectpeople.on.ca. B 
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